components/spider-tdl/src/task_context.rs (1)

30-40: ⚡ Quick win

Cover Commit and Cleanup in this round-trip test.

TaskContext.task_id now has three wire shapes, but this test only exercises TaskId::Index(0). A small table-driven round-trip over Index, Commit, and Cleanup would keep the termination-task serialization path covered too.

🧪 Suggested test shape

 #[test]
 fn round_trip_msgpack() -> anyhow::Result<()> {
-    let ctx = TaskContext {
-        job_id: JobId::new(),
-        task_id: TaskId::Index(0),
-        task_instance_id: 13,
-        resource_group_id: ResourceGroupId::new(),
-    };
-    let encoded = rmp_serde::to_vec(&ctx)?;
-    let decoded: TaskContext = rmp_serde::from_slice(&encoded)?;
-    assert_eq!(decoded, ctx);
+    for task_id in [TaskId::Index(0), TaskId::Commit, TaskId::Cleanup] {
+        let ctx = TaskContext {
+            job_id: JobId::new(),
+            task_id,
+            task_instance_id: 13,
+            resource_group_id: ResourceGroupId::new(),
+        };
+        let encoded = rmp_serde::to_vec(&ctx)?;
+        let decoded: TaskContext = rmp_serde::from_slice(&encoded)?;
+        assert_eq!(decoded, ctx);
+    }
     Ok(())
 }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@components/spider-tdl/src/task_context.rs` around lines 30 - 40, Update the
round_trip_msgpack test to iterate over the three TaskId wire shapes so Commit
and Cleanup are covered: create a small table (or array) of TaskId variants
including TaskId::Index(0), TaskId::Commit(some_id) and
TaskId::Cleanup(some_id), and for each variant construct a TaskContext (using
the existing fields like job_id, task_instance_id, resource_group_id), serialize
with rmp_serde::to_vec and deserialize with rmp_serde::from_slice, and
assert_eq!(decoded, original) for every case; modify the round_trip_msgpack
function to loop over these TaskId variants so the termination-task
serialization paths (Commit and Cleanup) are exercised.

tests/huntsman/task-executor/src/lib.rs (1)

186-202: ⚡ Quick win

Update docstring to reflect fixed task_id value.

The docstring states "The id fields are fresh per call", but task_id is now fixed at TaskId::Index(0) while job_id and resource_group_id remain fresh. The docstring should clarify this distinction.

📝 Proposed docstring update

 /// # Returns
 ///
-/// A placeholder msgpack-encoded [`TaskContext`] suitable for a one-shot test invocation. The id
-/// fields are fresh per call but the executor doesn't inspect them.
+/// A placeholder msgpack-encoded [`TaskContext`] suitable for a one-shot test invocation. The
+/// `job_id` and `resource_group_id` fields are fresh per call; `task_id` is fixed at `Index(0)`.
+/// The executor doesn't inspect these values.
 ///
 /// # Panics

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@tests/huntsman/task-executor/src/lib.rs` around lines 186 - 202, Update the
docstring for build_ctx to accurately reflect that not all id fields are fresh:
explain that job_id and resource_group_id are newly generated per call
(JobId::new(), ResourceGroupId::new()) while task_id is fixed to
TaskId::Index(0) and task_instance_id is 1; mention that encoding may panic on
failure as before and keep the must_use note.

tests/huntsman/task-executor/tests/test_process_pool.rs (1)

66-90: ⚡ Quick win

Update docstring to clarify which IDs are fresh.

The docstring states "fresh IDs", but task_id is now fixed at TaskId::Index(0) while job_id and resource_group_id remain fresh. Consider updating the docstring for clarity.

📝 Proposed docstring update

 /// # Returns
 ///
-/// A request with fresh IDs, a placeholder [`TimeoutPolicy`] (which the pool ignores — the caller
-/// supplies `hard_timeout` directly to [`ProcessPool::execute`]), and the supplied `inputs`.
+/// A request with fresh `job_id` and `resource_group_id`, fixed `task_id` at `Index(0)`, a
+/// placeholder [`TimeoutPolicy`] (which the pool ignores — the caller supplies `hard_timeout`
+/// directly to [`ProcessPool::execute`]), and the supplied `inputs`.
 fn make_request(task_func: &str, inputs: Vec<TaskInput>) -> ExecuteRequest {

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@tests/huntsman/task-executor/tests/test_process_pool.rs` around lines 66 -
90, The docstring for make_request is misleading: it says "fresh IDs" but only
job_id and resource_group_id are generated fresh while task_id is fixed to
TaskId::Index(0); update the function's docstring to explicitly state which IDs
are fresh (job_id and resource_group_id) and that task_id is intentionally fixed
to TaskId::Index(0) so callers understand the behavior; reference the
make_request function and the fields job_id, resource_group_id, and task_id in
the updated comment.